-
Notifications
You must be signed in to change notification settings - Fork 1.4k
OCPBUGS-56008: default Azure to create VM user-assigned identities #9718
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OCPBUGS-56008: default Azure to create VM user-assigned identities #9718
Conversation
@patrickdillon: No Jira issue with key OCPGBUGS-56008 exists in the tracker at https://issues.redhat.com/. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
@patrickdillon: This pull request references Jira Issue OCPBUGS-56008, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
/hold Not sure if this is what we want to do. I think so, but wanted to open it quickly for testing. |
11fc843
to
c032e69
Compare
/hold cancel |
@patrickdillon: This pull request references Jira Issue OCPBUGS-56008, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
Requesting review from QA contact: In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
c032e69
to
67e25c3
Compare
looking at the job, is it a regression?
|
@shellyyang1989 I'd guess that it's a permissions issue on the install for all of the CI Jobs :) QE testing IIUC shows this fixes the issue :) For context, the reason the installer team wanted to change this behaviour was to remove the User Access Admin Role from the install process, which means they'd no longer create a user identity at install time (at the request of a large customer, and to generally improve our security positioning). I don't think they realised at the time that the credential providers were relying on this identity! |
func defaultAzureMachinePoolPlatform() azuretypes.MachinePool { | ||
func defaultAzureMachinePoolPlatform(env azuretypes.CloudEnvironment) azuretypes.MachinePool { | ||
idType := capz.VMIdentityUserAssigned | ||
if env == azuretypes.StackCloud { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why are we special casing stackcloud? won't this then break stackcloud? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Azure Stack has never used node-attached identities, so I think we're safe here. TBH, I'm not certain why we never attached them, but the current state of this PR would continue the existing behavior we already have.
roleAssignmentsClient := clientFactory.NewRoleAssignmentsClient() | ||
roleAssignmentUUID := uuid.New().String() | ||
|
||
// XXX: Azure doesn't like creating an identity and immediately |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we love azure </3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one question but otherwise LGTM :)
} | ||
|
||
func createUserAssignedIdentity(ctx context.Context, in identityInput) error { | ||
userAssignedIdentityName := fmt.Sprintf("%s-identity", in.infraID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
most of the code in this function is existing code that is being restored from c26d2bb
67e25c3
to
49ab305
Compare
fixed up some nil pointer exceptions in the utils.go logic and updated some doc text. |
openshift#9538 switched the installer to not create user-assigned identities for VMs, and exposed an API for users to bring-their-own identities and attach them to nodes. OCPBUGS-56008 shows that the kubelet still depends on the node identity to pull images from Azure Container Registry (ACR). To resolve this issue, this commit sets the default back to using an installer-generated identity attached to the node. The API is still exposed in the install config, so users who do not utilize ACR can set the identity type to None and install with less privileged credentials. When upstream work lands to allow these credentials to be managed via credentialsrequests, we can go set the default identity to None and remove the logic for creating identities. The upstream work is tracked here and looks like it should be available in the next release: kubernetes/enhancements#4412
This restores code removed in c26d2bb for creating a user-assigned identity to attach to nodes. The code has been moved to its own file and is wrapped in a conditional so that the identity is only created when needed.
This commit conditionally sets fields in the cloud provider config to indicate that the the VM identity should be used to authenticate the ACR credential provider. If the installer is creating the identity then we set the cloud config to use that attached identity. This has been the behavior for openshif in all previous releases.
This revendors the azure packages that are needed to create a user-assigned identity.
49ab305
to
8e54931
Compare
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jhixson74 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@patrickdillon: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
a697e9b
into
openshift:main
@patrickdillon: Jira Issue OCPBUGS-56008: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-56008 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
[ART PR BUILD NOTIFIER] Distgit: ose-installer |
[ART PR BUILD NOTIFIER] Distgit: ose-baremetal-installer |
[ART PR BUILD NOTIFIER] Distgit: ose-installer-artifacts |
/cherry-pick release-4.19 |
@patrickdillon: new pull request created: #9731 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
#9538 changed the installer's default behavior so that it no longer created user-assigned identities and attached them to VMs for Azure installs. OCPBUGS-56008 revealed that the acr-credentials-provider still depends on the node identity and the missing identities breaks pulling images from private registries in Azure.
Simply reverting #9538 would cause additional issues, particularly:
This PR resolves these issues and the bug by keeping the install config API in place, but changing the default back so the installer continues to create and attach identities by default. ARO & internal Red Hat developers (assuming they don't need ACR) can set
installConfig.platform.azure.defaultMachinePool.identity.type: None
so that no identity is created.Upstream is working on a solution that will use credentials requests. Once that is landed, we can set the default identity type back to
None
and remove the code to create identities. Upstream tracker:kubernetes/enhancements#4412